xen: credit2: use the correct scratch cpumask.
authorDario Faggioli <dario.faggioli@citrix.com>
Thu, 9 Feb 2017 09:24:32 +0000 (10:24 +0100)
committerJan Beulich <jbeulich@suse.com>
Thu, 9 Feb 2017 09:24:32 +0000 (10:24 +0100)
commit23e33036f8d5f33add75d7fbecad13bcb2cb239e
treecadd290b13c7b72038426d52274f06e8f1815c0d
parent95f1f99a7a2a7c8fbf0eeb1dc6b8473d6e09f535
xen: credit2: use the correct scratch cpumask.

In fact, there is one scratch mask per each CPU. When
you use the one of a CPU, it must be true that:
 - the CPU belongs to your cpupool and scheduler,
 - you own the runqueue lock (the one you take via
   {v,p}cpu_schedule_lock()) for that CPU.

This was not the case within the following functions:

get_fallback_cpu(), csched2_cpu_pick(): as we can't be
sure we either are on, or hold the lock for, the CPU
that is in the vCPU's 'v->processor'.

migrate(): it's ok, when called from balance_load(),
because that comes from csched2_schedule(), which takes
the runqueue lock of the CPU where it executes. But it is
not ok when we come from csched2_vcpu_migrate(), which
can be called from other places.

The fix is to explicitly use the scratch space of the
CPUs for which we know we hold the runqueue lock.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reported-by: Jan Beulich <JBeulich@suse.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
master commit: 548db8742872399936a2090cbcdfd5e1b34fcbcc
master date: 2017-01-24 17:02:07 +0000
xen/common/sched_credit2.c